If a problem with a call arises in a telecommunications switch, e.g. one of the well known DMS switches of Nortel Networks, there may be considerable difficulties in establishing where the cause of the problem lies. In principle it can be caused by external factors (e.g. incoming signals or power supplies or physical environment factors being outside their expected ranges) or internal faults. Some internal faults will cause alarms to be triggered which can help enable the cause to be identified. If no alarms are triggered, a number of diagnostic tests may be undertaken to establish the cause of the problem.
For many switches, it is impractical to recreate their working conditions accurately in a laboratory environment, since they may have hundreds or thousands of calls being passed through them, with widely varying signal characteristics on the calls. Accordingly, the diagnosis must be made in the field, or at least with the switch operating under realistic load conditions. In this case, an attempt can be made to reproduce the fault condition by initiating a call over the same path as was used when the reported call processing problem occurred. The path may be identified from call processing records.
If the fault condition is repeatable, it is then desirable to locate the cause by monitoring the signals along the signal path or paths as they pass through the switch. However, a switch may have many physical paths with perhaps many signals time multiplexed on each physical path. This may be the case both inside the switch and at any trunks connected to the switch. In this case individual calls can be monitored either by listening at either end of a call path, where the individual signals have been demultiplexed from trunks, or by carrying out demultiplexing from the trunk specially for the purpose of monitoring.
Such special demultiplexing might involve broadcasting PCM (pulse code modulated) data streams of a trunk to an external channel bank for demultiplexing. The chosen call can then be recorded on a recorder. However, particularly for higher rate trunks, demultiplex equipment would be required to select 24 channels to be routed to the channel bank. It may be relatively expensive and time consuming to move and set up manually, and only captures problems which can be repeated on a predetermined one of the call paths.
Once the call is extracted, there is the problem of triggering when to start or stop recording. Since the signal on the call path gives an indication of whether a call is on-hook or off-hook, and of keypresses made by either party to the call, these can be used for triggering. However this is often insufficient to enable problems to be identified and cause triggering, particularly if the problem occurs irregularly. If the event causing the problem cannot be used for triggering, long recordings perhaps over hours or days may be needed to ensure a particular condition or signal is captured. This may tie up data recording resources wastefully, and may cause much time to be wasted searching the recording for the event.
The signal quality can be monitored either subjectively by listening, or by making objective measurements. However, such monitoring from outside a switch may be insufficient to enable the location of a fault within the switch to be identified accurately. One reason is that noise, delay and distortion may be introduced at different points along the call path in the switch.
Attempts to monitor signal quality or find where a signal gets mis-routed or mis-timed or timed out for example in a switch or between switches, have been made using external signal or logic analysers. However in many cases it is impractical to determine which of thousands of physical paths has been selected for the call in question, and it may be impractical to get access to internal events taking place in the control software of a switch to enable the analyser capture to be triggered appropriately. In short, the speed, or complexity or size of the switch or a combination of these factors may make the signals inaccessible to external monitoring equipment.
The term "call" is intended to encompass any type of end to end connection between users of the network, including those for voice, data or fax, and including virtual connections for which a physical path may not exist at all times. It is intended also to encompass connections made as one part of longer end to end connections, e.g. a data connection to a LAN user made by a remote worker dialling in over a telephone network to a LAN remote access gateway.
It is also known to have switches arranged for electronic wire tapping, which involves distinguishing and separating a given call, and diverting a "copy" of the call through the network outside the switch to a terminal connected to external recording equipment. In this case, what is recorded will be distorted by further passage through the network, with accompanying delays, and signal processing such as digital to analog conversion. Accordingly, in this case the signal that is captured is not the signal as it was in the call processing circuitry in the switch. Furthermore, there is no mechanism for triggering capture on faults. Also the call selection will be according to the telephone number, which may leave it difficult to identify exactly which call path within a switch is being used and captured. These constraints, and regulatory constraints makes it impractical to use this mechanism for problem tracing.
It is also known to record a signal entering a speech recognition system at the same time as recognition is attempted. If recognition is not achieved, the recording is available for an operator to listen to. In this case, there is no difficulty with accessibility of the signal, or timing the recording, since the speech recognition unit will typically be external to any switch and will have a single call path and handle one call at a time.